Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add explicit cn_validations field to PKI Roles #15996

Merged
merged 4 commits into from
Jun 16, 2022

Conversation

cipherboy
Copy link
Contributor

This new parameter allows disabling all validations on a common name, enabled by default on sign-verbatim and issuer generation options.

Presently, the default behavior is to allow either an email address (denoted with an @ in the name) or a hostname to pass validation. Operators can restrict roles to just a single option (e.g., for email certs, limit CNs to have strictly email addresses and not hostnames).

By setting the value to disabled, CNs of other formats can be accepted without validating their contents against our minimal correctness checks for email/hostname/wildcard that we typically apply even when broad permissions (allow_any_name=true, enforce_hostnames=false, and allow_wildcard_certificates=true) are granted on the role.


Resolves: #15596

@cipherboy cipherboy added this to the 1.12.0-rc1 milestone Jun 15, 2022
@cipherboy cipherboy requested a review from a team June 15, 2022 18:24
@cipherboy cipherboy requested a review from taoism4504 as a code owner June 15, 2022 18:24
@cipherboy cipherboy changed the title Add explicit cn_validation field to PKI Roles Add explicit cn_validations field to PKI Roles Jun 15, 2022
@cipherboy cipherboy force-pushed the cipherboy-add-explicit-cn-validation branch from e4805ab to ef2e484 Compare June 15, 2022 18:26
Copy link
Contributor

@stevendpclark stevendpclark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me.

I would like to see a call out in the help texts for the new param that the specified validations are or'd and not and'd together which is obviousish now but if we introduce others in the future might not be.

@cipherboy cipherboy force-pushed the cipherboy-add-explicit-cn-validation branch from ef2e484 to 6aeba62 Compare June 16, 2022 13:04
@cipherboy
Copy link
Contributor Author

@stevendpclark Clarified OR semantics hopefully. :)

@cipherboy cipherboy requested review from stevendpclark and a team June 16, 2022 13:04
Copy link
Contributor

@stevendpclark stevendpclark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clear to me, thanks!

This new parameter allows disabling all validations on a common name,
enabled by default on sign-verbatim and issuer generation options.

Presently, the default behavior is to allow either an email address
(denoted with an @ in the name) or a hostname to pass validation.
Operators can restrict roles to just a single option (e.g., for email
certs, limit CNs to have strictly email addresses and not hostnames).

By setting the value to `disabled`, CNs of other formats can be accepted
without validating their contents against our minimal correctness checks
for email/hostname/wildcard that we typically apply even when broad
permissions (allow_any_name=true, enforce_hostnames=false, and
allow_wildcard_certificates=true) are granted on the role.

Signed-off-by: Alexander Scheel <[email protected]>
Signed-off-by: Alexander Scheel <[email protected]>
@cipherboy cipherboy force-pushed the cipherboy-add-explicit-cn-validation branch from 6aeba62 to aa9b500 Compare June 16, 2022 13:37
@cipherboy cipherboy enabled auto-merge (squash) June 16, 2022 13:42
@cipherboy cipherboy merged commit 327fd02 into main Jun 16, 2022
@cipherboy cipherboy deleted the cipherboy-add-explicit-cn-validation branch December 1, 2022 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PKI: Some CN values are always rejected, even with allow_any_name and pki/sign-verbatim
2 participants